System and method for delegation of permissions to a third party

ABSTRACT

A system and method for delegating permissions to a third party are presented. A request to access a first computing resource of a computer server is received from a first user. The first user is prompted to supply a first authentication credential for access to the first computing resource of the computer server and the first authentication credential is received from the first user. After the first authentication credential is received, a request to access a second computing resource of the computer server is received from the first user. An authentication database is accessed to identify a second user associated with the second computing resource, and a request for a second authentication credential is transmitted to a second user. The second authentication credential is received from the second user. When the second authentication credential is received from the second user, the first user is given access to the second computing resource.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 14/719,211 entitled “SYSTEM AND METHOD FORDELEGATION OF PERMISSIONS TO A THIRD PARTY” and filed on May 21, 2015.

FIELD OF THE INVENTION

The present invention generally relates to the field of permissiondelegation and, specifically, to systems and methods for delegatingpermissions to a developer for maintaining and updating a web presence.

The present invention generally relates to the field of permissiondelegation and, specifically, systems and methods for delegatingpermissions to a developer for maintaining and updating a web presence.

SUMMARY OF THE INVENTION

The present inventions provide systems and methods comprising one ormore server computers communicatively coupled to a network.

In one embodiment, a method includes receiving, by a computer serverconfigured to communicate via a communications network and from a firstuser, a request to access a first computing resource of the computerserver, prompting, by the computer server, the first user to supply afirst authentication credential for access to the first computingresource of the computer server, and receiving, by the computer server,the first authentication credential from the first user. The methodincludes, after receiving, by the computer server, the firstauthentication credential, receiving, from the first user, a request toaccess a second computing resource of the computer server, accessing, bythe computer server, an authentication database to identify a seconduser associated with the second computing resource, transmitting, by thecomputer server, to the second user a request for a secondauthentication credential, and, when the second authenticationcredential is received from the second user, granting, by the computerserver, the first user access to the second computing resource.

In another embodiment, a method includes receiving, by a computer serverconfigured to communicate via a communications network and from a firstuser, a request to access a computing resource of the computer server,accessing, by the computer server, an authentication database toidentify a second user associated with the computing resource, andtransmitting, by the computer server, to the second user a request foran authentication credential. The method includes receiving, by thecomputer server, from the second user the authentication credential.

In another embodiment, a system includes an authentication databaseassociating at least one user with at least one computing resource and acomputer server configured to communicate with the authenticationdatabase. The computer server is configured to receive, from a firstuser, a request to access a computing resource, access theauthentication database to identify a second user associated with thecomputing resource, transmit, to the second user, a request for anauthentication credential, and receive, from the second user, theauthentication credential.

In another embodiment, a method includes receiving, by a computer serverconfigured to communicate via a communications network and from a firstuser, an electronic communication encoding a listing of products thatare available for purchase. The electronic communication identifies asecond user. The method includes storing, by the computer server, thelisting of products in a database in association with a key, accessing,by the computer server, a user accounts database to determine whetherthe first user is a delegate of the second user, and, when the useraccounts database contains a record indicating that the first user is adelegate of the second user, the computer server:

In another embodiment, a method includes receiving, by a computer serverconfigured to communicate via a communications network and from a firstuser, an electronic communication encoding a listing of products thatare available for purchase. The electronic communication identifies asecond user. The method includes storing, by the computer server, thelisting of products in a database in association with a key, encoding,by the computer server, the key into a link in a second electroniccommunication configured for display on a client device, andtransmitting, by the computer server, the second electroniccommunication to the second user identified in the first electroniccommunication, the second electronic communication identifying the firstuser.

In another embodiment, a system includes a database configured to storeat least one listing of products in association with at least one key,and a computer server. The computer server is configured to receive,from a first user, an electronic communication encoding a listing ofproducts that are available for purchase. The electronic communicationidentifies a second user. The computer server is configured to store thelisting of products in the database in association with a key, encodethe key into a link in a second electronic communication configured fordisplay on a client device, and transmit the second electroniccommunication to the second user identified in the first electroniccommunication. The second electronic communication identifies the firstuser.

The above features and advantages of the present invention will bebetter understood from the following detailed description taken inconjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an environment in which aspectsof the present invention may be implemented.

FIG. 2 is a screenshot illustrating an example user interface that maybe used by a developer to register as a developer with a host.

FIG. 3 is a flowchart illustrating an example method for a registereddeveloper to add a client.

FIGS. 4A-4E are screen shots depicting various steps in a method for aregistered developer to add a client and receive notification of thesame.

FIG. 5 is a block diagram illustrating a multi-factor authenticationscheme for a developer where a client is required to provide at leastone of the authentication tokens.

FIG. 6 is a flowchart illustrating a method for a developer to shop forproducts on behalf of a client.

FIGS. 7A-7C are screen shots depicting various steps in a method for adeveloper to shop for products for a client.

DETAILED DESCRIPTION

The present invention will now be discussed in detail with regard to theattached drawing figures that were briefly described above. In thefollowing description, numerous specific details are set forthillustrating the Applicant's best mode for practicing the invention andenabling one of ordinary skill in the art to make and use the invention.It will be obvious, however, to one skilled in the art that the presentinvention may be practiced without many of these specific details. Inother instances, well-known machines, structures, and method steps havenot been described in particular detail in order to avoid unnecessarilyobscuring the present invention. Unless otherwise indicated, like partsand method steps are referred to with like reference numerals.

A network is a collection of links and nodes (e.g., multiple computersand/or other devices connected together) arranged so that informationmay be passed from one part of the network to another over multiplelinks and through various nodes. Examples of networks include theInternet, the public switched telephone network, the global Telexnetwork, computer networks (e.g., an intranet, an extranet, a local-areanetwork, or a wide-area network), wired networks, and wireless networks.

The Internet is a worldwide network of computers and computer networksarranged to allow the easy and robust exchange of information betweencomputer users. Hundreds of millions of people around the world haveaccess to computers connected to the Internet via Internet ServiceProviders (ISPs). Content providers place multimedia information (e.g.,text, graphics, audio, video, animation, and other forms of data) atspecific locations on the Internet referred to as websites. Thecombination of all the websites and their corresponding web pages on theInternet is generally known as the World Wide Web (WWW) or simply theWeb.

Prevalent on the Web are multimedia websites, some of which may offerand sell goods and services to individuals and organizations. Websitesmay consist of a single webpage, but typically consist of multipleinterconnected and related web pages. Websites, unless extremely largeand complex or have unusual traffic demands, typically reside on asingle server and are prepared and maintained by a single individual orentity. Website browsers are able to locate specific websites becauseeach website, resource, and computer on the Internet has a uniqueInternet Protocol (IP) address.

IP addresses, however, even in human readable notation, are difficultfor people to remember and use. A Uniform Resource Locator (URL) is mucheasier to remember and may be used to point to any computer, directory,or file on the Internet. A browser is able to access a website on theInternet through the use of a URL. The URL may include a HypertextTransfer Protocol (HTTP) request combined with the website's Internetaddress, also known as the website's domain name.

Domain names are much easier to remember and use than theircorresponding IP addresses. The Internet Corporation for Assigned Namesand Numbers (ICANN) approves some Generic Top-Level Domains (gTLD) anddelegates the responsibility to a particular organization (a “registry”)for maintaining an authoritative source for the registered domain nameswithin a TLD and their corresponding IP addresses.

In a number of situations a domain name registrant will work with adeveloper to create and maintain the registrant's online web presence.This may involve working with a web developer to register a domain nameand create a corresponding website and manage and maintain content thatis present on the website. The web developer may be an entity thatincludes professionals well versed in website programming languages, aswell as copy writing and visual or graphic design. The developer mayalso offer other services, such as social media management, which mayinvolve monitoring and distributing content through one or more socialmedia networks using accounts affiliated with the registrant. Where theregistrant is a small business, for example, this may involveinteracting with the business' customers to answer queries and provideassistance.

When developing the registrant's website, the developer may be reliedupon to build the registrant's primary website, as well as implement anumber of technologies that are operated in association with thatprimary website. For example, if the registrant is a small business andoffers products and/or services for sale through its website, thedeveloper may be relied upon to implement a shopping cart functionalityon the website enabling customers of the website to browse availableproducts and services and then purchase the same. In a similar fashion,the developer may be relied upon to implement an accounting softwaresystem for such a small business.

In conventional arrangements, it can be difficult for a domain nameregistrant to work effectively with a third party developer. In therelationship, the developer is generally the expert and has a betterunderstanding of what tools, products and services the registrant needsto develop their online presence. Even so, the registrant is generallytasked with purchasing those tools, products, and services based uponthe developer's recommendations. In some cases, the purchase process forsuch products can be complicated and technical requiring the registrantto select between options and features with which the registrant may notbe familiar. For example, when purchasing hosting services, theregistrant may be required to select between options providing varyingamounts of storage capacity, bandwidth, peak bandwidth, and the like.Hosting services may also be provided using a number of differentunderlying operating systems and web servers, which themselves mayinclude different purchase options for installed modules enablingdifferent functionality. Similarly, when purchasing search engineoptimization (SEO) services, purchase options may include the selectionof potential keywords at different costs, and one or more search enginesupon which to implement the SEO services.

As such, the product purchase process may often involve the registrantbeing unable to confidently select between the one or more optionsavailable for a particular product. As a consequence, the registrant maybe reduced to calling or meeting with the developer in person so thatthe correct selections can be made and the products purchased. Ofcourse, this wastes valuable time and money, requires additionalcommunications between the developer and registrant, and can createfrustration. This is particularly true in the instance that theregistrant makes an incorrect selection and either purchases the wrongtool, product, or service.

In many cases, this complexity has resulted in a number of domain nameregistrants simply handing over a credit card or other paymentinstrument to a developer enabling the developer to purchase requiredproducts and services on behalf of the registrant. Of course, thisoption presents a number of difficulties, too. First, there is noconstraint to what the developer is able to purchase with the paymentdevice provided by the registrant. Even perfectly innocently, amiscommunication between registrant and developer could lead to thedeveloper purchasing unwanted products or services, or selecting optionsassociated with the products or services that make them more expensivethan desired by the registrant.

Furthermore, once the products or services have been purchased, thedeveloper must find some way to transfer ownership of the purchasedproducts and services back to the domain name registrant. This oftenrequires that the developer configure the purchased products or serviceswith passwords known to the registrant or provided to the registrantafter the products and/or services are purchased. Again, this can bequite cumbersome.

Even after the products or services are purchased, the developer mayrequire ongoing access to the products or services so as to configurethem in accordance with the registrant's wishes. This usually requiresthat the registrant and developer share account details (e.g., usernameand password) enabling both parties to access the products or services.As the password must be shared between the parties, the password isusually arbitrary and prone to being lost or forgotten. In many cases,the registrant, being too unsophisticated to modify the accountcredentials for the product or services, will simply continue using thesame username and password, meaning that the developer may have ongoingaccess to the registrant's products and/or services even after therelationship between the registrant and the developer has been otherwiseterminated.

The present system and method is configured to facilitate the workingrelationship between registrant and developer. The system as describedherein allows a registrant and developer to work together to ensure thata correct set of products and services are purchased as part of theregistrant's online presence. The system then enables the registrant,after becoming a client of the developer, control over the access rightsof the developer to those products and services (as well as otherproducts and services registered to the registrant), which ensures thedeveloper has sufficient access to the products and services toeffectively work on behalf of the registrant to develop the registrant'sonline presence.

FIG. 1 is a block diagram illustrating an example environment in whichthe present system and method may be implemented. As shown, environment100 includes host 102 configured to communicate with a number ofdifferent entities via a communications network 104. Communicationsnetwork 104 may include the Internet, a public switched telephonenetwork, computer networks (e.g., an intranet, an extranet, a local-areanetwork, or a wide-area network), wired networks, wireless networks, andthe like.

Host 102 makes available a number of different products to customers 106to allow customers 106 to create and manage their online presence. Forexample, host 102 may provide domain name (DN) registration services 108that enable a user to search for and register a desired domain name.Host 102 may also provide hosting services 110 allowing a user to hostwebsite content with host 102 as well as a website builder 112 toolenabling a user to modify and create content for a website that may behosted on hosting services 110.

Host 102 may provide a number of other products that can be utilized inconjunction with a website hosted on hosting services 110, such as SEOservices 114 and shopping cart 116 functionality. Other types ofproducts that may be provided by host 102, but are not illustrated inFIG. 1, include domain name transfer services, private domain nameregistration, domain name system (DNS) services, secure communicationscertificate creation and management (e.g., secure socket layercertification creation), email services, logo design services, andmarketing solutions (e.g., local service business listing services,restaurant menu management).

Host 102 stores customer records in user account records database 118 tomaintain a listing of which products or services have been purchased bya particular customer 106. During normal use, a customer would create anaccount with host 102 and then register one or more of the productsprovided by host 102. Once a product is registered, the customer canaccess the product to create and modify settings associated with theproduct, upload content to the product, and modify various attributes ofthe product.

A front of site 120 website is provided by host 102 enabling a customer106 to authenticate to host 102 and then access and/or purchase one ormore of the products or services offered by host 102.

In the present system, customer 106 may elect to delegate someresponsibilities to developer 122 to access and modify one or more ofthe products that have been purchased by customer 106. Once delegatedto, developer 122 authenticates to front of site 120 website and canthen access the one or more products or services of customer 106 towhich the developer 122 has been granted access. Generally, when actingas delegate, developer 122 may be said to be impersonating customer 106so that when viewing one of the products that customer 106 hasregistered, developer 122 sees generally when customer 106 would seewhen viewing the product.

Depending upon the permission level granted to developer 122 by customer106, as part of the delegation developer 122 may only be able to accessor view a particular product and the contents thereof or may, in somecases, have the rights to access a product and make changes therein oreven delete or remove the product. As such, the delegation may allowdeveloper 122 to modify one or more of the products of customer 106 onbehalf of customer 106.

When the products of customer 106 have been appropriately configured byeither customer 106 or developer 122 (which may involve creatingsettings for the various products, or uploading or creating content inone or more of the products), content associated with the products canbe published by host 102 and accessed by public users 124 via network104.

In the present system, before working with customer 106, developer 122creates a developer account with host 102. FIG. 2 is a screenshotillustrating an example form 200 that may be completed by a developer toregister as a developer with host 102. Form 200 may be displayed on asuitable website by host 102 enabling developer 122 to create adeveloper account with host 102.

As shown, form 200 allows a developer to both create an account andprovide information describing the developer. For example, the developermay upload a logo 202 to be incorporated into communications transmittedby host 102 on behalf of developer 122. The logo may be uploaded as astill graphic image or may include animation or video. Developer 122 canalso provide identifying information such as the developer's name andbusiness name. Form 200 may also be used by developer 122 to supplycontact information, such as email address 208 and telephone number 210.

In other embodiments, when developer 122 is creating an account, form200 may be modified to capture more or different data about developer122's business. For example, form 200 may capture information such as adescription of the services offered by developer 122 as well as prices(or estimates of prices) for the same. Additionally, information such asthe location of developer 122 could be captured by form 200 enablingpotential customers 106 in proximity to developer 122 to be identified,where the proximity may enable or facilitate in-person meetings betweendeveloper 122 and a customer 106.

After developer 122 has created an account with host 102, theinformation submitted through form 200 is captured by host 102 andstored in an appropriate data storage system (e.g., user account recordsdatabase 118 of FIG. 1) and may be utilized to provide customers 106 ofdeveloper 122 with a consistent branding experience for allcommunications initiated to customers 106 by host 102. This may involve,for example, always displaying developer 122's company name and logo inall communications transmitted by host 102 on behalf of developer 122 sothat the developer 122's brand is regularly displayed to the customersallowing developer 122 to develop some brand loyalty with customers ofdeveloper 122.

After developer 122 has provided all the information requested by form200, developer 122 clicks button 212 to initiate the creation of adeveloper account. At that time, host 102 receives all of theinformation that developer 122 entered into form 200 (including,optionally, a logo for developer 122). That information can then bestored in a suitable database (e.g., user account records database 118)by host 102 for later retrieval.

After developer 122 has created a developer account with host 102,developer 122 can add one or more customer 106 as a client of developer122. FIG. 3 is a flowchart illustrating an example method for aregistered developer 122 to add a client.

Referring to FIG. 3, in step 302 developer 122 provides contactinformation for the new client. In some cases, the new client mayalready be a customer 106 of host 102, however in other cases the newclient will not be a customer 106 and may, therefore, ultimately need tocreate a new customer account with host 102.

In many cases, developer 122 will have already met the individual orteam that is to become the new client. For example, following aninterview process (either formal or informal), developer 122 and the newclient may determine that they wish to work together. At that time, thenew client may provide the developer 122 with contact information (e.g.,by sharing a business card or social network contact information)enabling the developer 122 to add the client as a new client accordingto the present method.

FIG. 4A shows an example user interface enabling developer 122 toprovide contact information for the potential new client. The interfaceenables developer 122 to provide contact information for the new client,including name and email address. The form also provides an option toallow developer 122 to add products on behalf of the new client (seebutton 401). This option is described in detail below.

Returning to FIG. 3, after developer 122 has provided the contactinformation for the new client, in step 304 host 102 receives thecontact information and transmits a request to the client. The requestasks that the client confirm that they wish to be added as a client ofdeveloper 122. At this time, the client is put into a pending state.

FIG. 4B shows an example user interface that may be displayed todeveloper 122 to show that a new client invite has been sent (e.g.,following completion of step 304 of FIG. 3). As shown, the userinterface shows that the account is pending (i.e., the new client hasnot become a formal client of developer 122) and that, at this time,developer 122 has no access to any of the products or services of thenew client. As such, the account access is pending. The potential newclient will stay in this state (with developer 122 having no access)until the request is accepted by the new client and account access isgranted.

FIG. 4C shows an example message that may be transmitted to the newclient upon completion of step 304 of FIG. 3. As illustrated, themessage identifies the developer 122 that has caused the request to beissued—the request includes the developer 122's contact information, andlogo 402 and requests that developer 122 be given access to thepotential new client's products with host 102.

If the potential new client wishes to become a client of developer 122,the new client clicks upon button 404. After clicking button 404 theuser will be asked to authenticate to host 102 (e.g., by providing ausername and/or password).

In the event that the new client is not already a customer of host 102,the new client, after clicking button 404 may elect to create a newcustomer account with host 102. During the new customer accountcreation, the new client will provide a username and password that willbe used to authenticate the new client to host 102 in the future.

After authenticating with host 102, as shown in step 306 of FIG. 3, thenew client will be provided with an opportunity to become a client ofdeveloper 122 by specifying a set of permissions for developer 122.

In one embodiment, the client may be able to set relatively simplepermissions for developer 122. For example, the client may only be ableto select between giving developer 122 access to manage all of theproducts to which the user has subscribed with host 102, or permissionto both manage those products as well as purchase new products on behalfof the user. An example of such a user interface is shown in FIG. 4D. Asillustrated, the interface includes radio buttons 406, which allow theuser to select between the two permission options that will be grantedto developer 122.

With reference to FIG. 4D, after the user has selected the desiredpermission options, the user selects button 407 to set the desiredpermissions (the permissions may be stored by host 102 in a suitabledata storage device, for example) and cause a notification to betransmitted to developer 122 informing developer 122 that the user hasset a permission level for developer 122. At that time, the user will betransitioned into an active client of developer 122 and developer 122will have access to the user's purchased products and, depending uponthe permission level granted, can begin working to modify and updatethose products to develop the user's web presence. If the user givedeveloper 122 permission to make purchases on behalf of the user, theuser may specify a monetary limit that developer 122 cannot exceed inmaking such purchases. In one embodiment, the user may be able to grantdeveloper 122 permission to all aspects of the user's account with host102. Such a grant of permissions would allow developer 122 to update theuser's personal information such as name and telephone number as well aspayment information. To provide adequate security, this permission levelmay be limited temporally to prevent abuse or misuse. In other cases,the user may grant permissions to developer 122 to manage the user'sstored payment information. This could be useful to allow developer 122to take the steps necessary to ensure that product renewals take placeas necessary.

In other embodiments, the system may allow the user much more controlover the permissions that are to be granted to developer 122. Forexample, the user may be able to specify different specific sets ofpermissions (e.g., create, modify, and/or delete) for each product towhich the user is a subscriber. Because different actions may beassociated with different products, the available types of permissionsmay vary for different products. For example, for a website builderapplication, the permissions may center on whether the developer has theability to modify existing content, create new content, or deletecontent. In some cases, the option to delete content may be furtherdelineated so that the client can specify whether the developer can onlydelete content that the developer has created, or whether the developercan delete additional content (e.g., content created by the client hisor herself). The set of permissions that may be available for hostingservices, in contrast, may include whether the developer has the abilityto take down an instance of the client's website or purchase a newinstance. Table 1, below, shows an example set of permission options fora particular user in such an implementation for various differentproducts.

TABLE 1 Product Possible Permissions Website Builder Application create,modify, and/or delete content SEO services create, modify, and/or deletesettings DNS Services create, modify, and/or delete records HostingServices Take down an instance and/or purchase a new instance

In some cases, the permissions may be granted for a limited time so thatany permission given to developer 122 will expire.

With permissions delegated to developer 122, the client will appear asan active client in the dashboard of developer 122. To illustrate, FIG.4E is a screenshot showing an example dashboard for developer 122following the grant of permissions by a client. As shown in FIG. 4D, theclient (in this example, Susan Jones) has subscribed to twoproducts—domain name and hosting. By selecting one of buttons 408,developer 122 can access either of the client's products to make changesthereto in accordance with the permissions that were granted by theclient.

In another embodiment, in addition to specifying specific permissionlevels for developer 122, the client can also specify the form in whichthe developer must authenticate to host 102 before being given access tothe client's products. The form of authentication may be establishedgenerally for all of the client's products or may be established on aproduct-by-product basis. In another embodiment, specific forms ofauthentication may be established for certain actions that developer 122may taken within one or more of the client's products.

For example, a normal single-factor authentication may be required toallow developer 122 to access the client's website builder account andmake modifications to the user's website. However, if developer 122wishes to delete the user's website (or even just one or more web pagesof the user's website), a two factor authentication may be requiredbefore such an action may be implemented. Similarly, single factorauthentication may be required before developer 122 can purchase newdomain names on behalf of the user. However, if developer 122 attemptsto transfer one of the user's registered domain names out of the user'sname to another entity, such an action may require two factorauthentication before the transfer can be implemented.

In a basic implementation, developer 122 would be required toauthenticate as developer 122 before being given access to the user'sproducts. This could involve, for example, developer 122 supplying theuser name and password associated with the developer 122's developeraccount established with host 102.

In other embodiments, the client may choose to specify that thedeveloper 122 be required to authenticate to host 102 using two factorauthentication. In that case, not only must developer 122 supply apassword in order to be authenticated, but developer 122 may also berequired to be supply a second factor (e.g., a second token) in order tobe granted access to the client's products. This may involve, forexample, developer 122 being required to provide to host 102 a token orcode that has been previously transmitted to the developer 122's smartphone via short messaging service (SMS) message. In other cases, thesecond factor may be a biometric token, such as a fingerprint ofdeveloper 122 (e.g., submitted to host 102 via an appropriatelyconfigured fingerprint scanner), and iris scan of developer 122 (e.g.,submitted to host 102 via an appropriately configured iris scanner), ora photograph of the developer 122 (e.g., submitted via an image orphotograph captured via a camera capability of a smart phone belongingto developer 122). In other embodiments, more than two factorauthentication may be required so that developer 122 may be required tosupply three or more security tokens to host 102 before being grantedaccess to the user's products.

When using multi-factor authentication, developer 122 may be required toprovide all the tokens required as part of the authentication scheme.For example, developer 122 may be required to provide a password, atoken that was supplied via SMS message to developer 122's mobiledevice, fingerprint data, and any other token that may be used forauthentication.

In other embodiments of a multi-token authentication scheme, the tokensmay be required to be provided by both developer 122 and the client,before developer 122 can be authenticated and given access to the user'sproducts. For example, FIG. 5 is a block diagram illustrating amulti-factor authentication scheme for developer 122 where a client isrequired to provide at least one of the authentication tokens. FIG. 5includes a simplified version of the environment illustrated in FIG. 1.As illustrated, the environment includes host 102 and developer 122. Inthis example developer 122 has a client 502. Client 502 has givenpermission to developer 122 to access client 502's products. But, ingiving that permission, client 502 has specified that developer 122 willneed to authenticate using two factor authentication, where the secondtoken in the authentication scheme must be provided to host 102 byclient 502 rather than developer 122 because any such access is granted.

Under such a scheme, developer 122 may first authenticate to host 102via a conventional authentication scheme (e.g., by providing a user nameand password, and, optionally, providing secondary authenticationfactors) as indicated by arrow (1). Developer 122 may authenticate inthis manner specifically to access the products of client 502. Or,alternatively, developer 122 may simply authenticate in this manner inorder to access developer 122's own account or to access the products ofanother client.

At some point after the initial authorization, however, as indicated byarrow (2), developer 122 wishes to access the products of client 502.Note that developer 122 has previously received permission from client502 to access the products of client 502.

Upon receiving the request from developer 122, host 102 accesses thepermission record that was created by client 502 for developer 122. Thepermission record may be stored, for example, in an authenticationdatabase that is part of or separate from user account records database118 depicted in FIG. 1 and describes the permissions that were grantedto developer 122 by client 502. In the present example, because thepermission record indicates that two-factor authentication is to beimplemented, with the second factor being provided by client 502, host102 transmits a request for the second token to client 502, as indicatedby arrow (3).

The step indicated by arrow (3) may be implemented in any suitablemanner. In one example, host 102 is configured to transmit a text tokento a mobile device belonging to client 502. An example message may be,for example “Your validation code is ######. This code will expire in 20minutes.” The code could include, for example, a combination of lettersand numbers. Upon receiving the text token, client 502 responds to host102 either by entering the token into a web page provided by host 102,by transmitting the token back to host 102 via SMS message, or using anyother suitable technique.

By providing the token back to host 102 (see arrow (4)), client 502 isrequired to be part of the two-factor authentication process by whichdeveloper 122 accesses client 502's products. This ensures thatdeveloper 122 is not accessing client 502's products without theknowledge of client 502. Additionally, in cases where client 502 anddeveloper 122 have not worked together in sometime, this two-factorauthentication scheme can act as a reminder to client 502 that client502 had previously delegated permission to developer 122, shoulddeveloper 122 try to access client 502's products at a later date.

This scheme, therefore, provides a secure authentication approach thatensures client 502 is made aware when developer 122 is accessing client502's products.

In some embodiments, developer 122 may be given temporary access (whichmay optionally be limited to read-only access) to the account of client502, while the system waits for client 502 to provide the second token.This would allow developer 122 to perform some work within the accountof client 502 even if client 502 takes some time to provide thenecessary token. In such an implementation, any changes that developer122 attempts to make to the account of client 502 could be heldtemporarily and not implemented until client 502 provides the securitytoken, at which time the changes would be implemented.

Although this authentication scheme is described in terms of client 502delegating web development responsibilities and permissions to adeveloper 122, it should be understood that this two-factorauthentication scheme may be utilized in any situation calling forauthentication of a first individual or entity where it is beneficialthat a second individual or entity be made part of (and, thereby, awareof) the first individual or entity's attempt to authenticate to aparticular system.

In some embodiments, rather than transmit a request for a second tokento client 502, a notification that developer 122 has accessed one of theproducts of client 502 may be transmitted to client 502. In such animplementation, there would be no delay for developer 122 to access theproducts of client 502 while the system waits for client 502 to returnthe security token. In any case, client 502 would be made aware thatdeveloper 122 is accessing client 502's account and, if that access isnot desired, client 502 could take suitable steps to revoke developer122's access.

In a similar manner, rather than require that client 502 provides thesecurity token, client 502 could instead be provided with a notificationof proposed changes being made to client 502's account. Upon review ofthose proposed changes, client 502 could elect whether to approve ordisapprove of the changes being made. If approved, the changes, whichwould otherwise be held temporarily, would be implemented. If notapproved, the changes would be discarded resulting in no modification toclient 502's account.

After developer 122 has been authenticated using the form ofauthentication that was specified by the user, developer 122 can bedesignated as a delegate of the client 502. Accordingly, as illustratedby arrow (5) in FIG. 5 a cookie (which may, in various embodiments, be asecure cookie) may be set on a computing device of developer 122 thatindicates developer 122 is a delegate of client 502. As developer 122navigates through websites and products made available by host 102, thesecure cookie will provide developer 122 with access to the products ofclient 502 in accordance with the permissions granted by client 502.

In various embodiments of the present system, developer 122 may shop forproducts on behalf of a client. As discussed above, because developer122 has particular knowledge of the products needed by the client—aknowledge that may not be accessible to the client—it may facilitatedeveloper 122's work to allow developer 122 to shop on behalf of theclient.

In the present system, developer 122 is able to browse through thevarious product offering of host 102 and select one or more of theproducts to create a shopping list. Once created, that shopping list canbe forwarded to the client of developer 122 with a notification that theshopping list was prepared by developer 122 for the client.

Upon receipt, the client can review the shopping list and choose topurchase the items on the shopping list as is, or to make modificationsto the order before purchasing.

If the client is not yet a formal client of developer 122 (i.e., theclient has not yet granted permission to developer 122 to the client'sproducts with host 102), upon approving of the shopping list, the clientmay choose to grant permission to the various items being purchasedpursuant to the permission options described herein.

Following purchase of the items (and, potentially, the granting ofpermission to the items to developer 122) developer 122 receives anotification letting developer 122 know that they can access theclient's products.

FIG. 6 is a flowchart illustrating a method for developer 122 to shopfor products on behalf of a client. In step 602, developer 122authenticates to a website hosted by host 102. This allows host 102 toknow the identity of developer 122 as developer 122 constructs theshopping list.

In step 604, developer 122 browses the available products in a catalogof products made available by host 102. While browsing, developer 122selects one or more products to add to a shopping list for a particularclient. In selecting the one or more products, developer 122 may makeselections of particular attributes of the various products dependingupon the needs of the client of developer 122.

In step 606, developer 122 completes the shopping list. At this time,host 102 receives the contents of the shopping list and stores thelisting (along with all product-specific purchase details) in a storagedatabase (e.g., shopping list database 126 of FIG. 1). The databaseentry containing the shopping list is associated with developer 122(e.g., by including an identification code associated with developer 122in the database entry). The shopping list is also allocated a key (e.g.,an ID number that uniquely identifies the shopping list) that may beused to identify and retrieve the contents of the shopping list from thestorage database.

At this time, a client for the shopping list may be identified. If, forexample, developer 122 created the shopping list by navigating throughthe dashboard of the developer 122 and selecting a button to shop onbehalf of a particular client (see, for example, button 409 of FIG. 4E)or as part of creating a new client for developer (see, for example,button 401 of FIG. 4A), the client may be identified implicitly by theactions of developer 122. If it is not possible to implicitly identifythe client for whom developer 122 has been shopping, host 102 mayexplicitly prompt developer 122 to provide an identification of theclient (e.g., name and email address) for whom developer 122 has beenshopping.

In step 608, after identifying the client for whom developer 122 hasbeen shopping, host 102 creates an electronic message to be transmittedto the client (e.g., an email message, email message containing a linkto a web page, web age, SMS message, and the like) that notifies theclient that developer 122 has created a shopping list for the client.The message may include a link to the shopping, where the key that wasoriginally associated with the shopping list when it was stored inshopping list database is encoded into the link. An example linkcontaining the key is depicted in Table 2, below, where the key includesthe string “44.” The message may include an identification of developer122 that created the shopping list, which may include developer 122'sname, business name, and logo.

TABLE 2https://pro.godaddy.com/shopping_list/44/accept?&isc=gdbb3043&ci=95067&cvosrc=bounceback.3043.gdbb3043

In one embodiment, the electronic message transmitted to the client mayinclude a summary of the items that developer 122 has included in theshopping list. To illustrate, FIG. 7A is a screen shot of an electronicmessage that may be transmitted to a client to inform the client of ashopping list that has been created on their behalf. As illustrated inFIG. 7A, the message includes a summary of the products that were addedto the shopping list, as well as an indication of developer 122,including developer 122's logo and business information.

The user interface includes a link 702 that, when executed, allows theclient to review the details of the shopping list and make adetermination of whether the client wishes to purchase the items on theshopping list.

After the user executes link 702, host 102 receives the indication thatthe link has been executed and retrieves the key that was originallyembedded into the link from the executed link. Host 102 can then use thekey to retrieve the details of the shopping list from shopping listdatabase 126. Having retrieved the details of the shopping list, host102 creates a user interface such as that depicted in FIG. 7B for theclient providing the client with a detailed summary of the itemscontained in the shopping list.

In one embodiment, the level of details included in the user interfaceof FIG. 7B may vary depending upon whether the shopping list was createdby developer 122. If so, the user interface created by host 102 may besimplified and provide a simple summary of the items contained withinthe shopping list. Such an interface may include limitedcross-selling/upselling of other products so as to minimize confusionfor the client and to prevent the user from purchasing incorrect items.In one embodiment, host 102 can determine whether the shopping list wascreated by developer 122 by determining whether the database entrycontaining the shopping list includes an association with developer 122.

In step 610, after reviewing the items contained in the shopping list(and, optionally, modifying the list of items contained therein), theclient approves of the items on the shopping list and initiates atransaction for purchase of the same. Because the shopping list wasoriginally prepared by developer 122, after purchasing the items, instep 612 the client is provided an opportunity to set the permissionsgranted to developer 122 for the items newly purchased.

FIG. 7C is a screenshot showing an example user interface enabling theclient to select particular permissions levels for products that werepurchased using a shopping list created by a developer. As illustrated,the interface includes a number of radio buttons 704 enabling the userto select between different permissions levels for therecently-purchased products. In accordance with the various embodimentsdescribed herein, at this point the client may be provided with manydifferent options regarding the permissions to grant to developer 122for each of the listed products. For example, the client may be able tospecify particular levels of permissions for each product purchasedindependently of one another. Furthermore, the client may be able tospecify a particular form of authorization (e.g., single factorauthentication, multi-factor authentication, or multiple factorauthentication where one factor is provided by the client) for each ofthe client's products and may even specify a particular form ofauthorization that must be undertaken by developer 122 before developer122 can take particular actions in one or more of the client's products.

Returning to FIG. 6, following the client's setting of permissions fordeveloper 122, in step 614 a notification is sent to developer 122informing developer 122 that products have been purchased based upon theshopping list originally sent to the client and that developer 122 maynow have access to the one or more products.

The steps included in the embodiments illustrated and described inrelation to the various figures are not limited to the embodiments shownand may be combined in several different orders and modified withinmultiple other embodiments. Although disclosed in specific combinationswithin these figures, the steps disclosed may be independent, arrangedand combined in any order and/or dependent on any other steps orcombinations of steps.

Other embodiments and uses of the above inventions will be apparent tothose having ordinary skill in the art upon consideration of thespecification and practice of the invention disclosed herein. Thespecification and examples given should be considered exemplary only,and it is contemplated that the appended claims will cover any othersuch embodiments or modifications as fall within the true scope of theinvention.

The Abstract accompanying this specification is provided to enable theUnited States Patent and Trademark Office and the public generally todetermine quickly from a cursory inspection the nature and gist of thetechnical disclosure and in no way intended for defining, determining,or limiting the present invention or any of its embodiments.

The invention claimed is:
 1. A method, comprising: authenticating, by acomputer server configured to communicate via a communications network,a website developer; after authenticating, by the computer server, thewebsite developer, receiving from the website developer a request toaccess a computing resource of the computer server; providing thewebsite developer temporary access to the computing resource, thetemporary access to the computing expiring after a period of time;identifying, by the computer server, a user, wherein the computingresource is registered to the user; transmitting, by the computerserver, to the user a request for an authentication credential grantingthe website developer access to the computing resource; and uponreceiving, by the computer server, the authentication credential,providing the website developer permanent access to the computingresource.
 2. The method of claim 1, wherein the request for theauthentication credential is transmitted to the user using a shortmessage service message.
 3. The method of claim 1, wherein theauthentication credential includes an image.
 4. The method of claim 1,further comprising, before providing the website developer temporaryaccess to the computing resource, accessing an authentication databaseto determine that the user has previously granted access to thecomputing resource to the website developer.
 5. The method of claim 1,wherein the computing resource includes at least one of a websitebuilder application, a search engine optimization tool, and an emailservice.
 6. The method of claim 1, including, after receiving from theuser the authentication credential: accessing an authentication databaseto determine a permission level of the website developer for thecomputing resource; and restricting actions of the website developerwith respect to the computing resource in accordance with the permissionlevel.
 7. The method of claim 1, including, after receiving from theuser the authentication credential, setting a secure cookie on a firstuser device of the website developer, the secure cookie indicating thatthe website developer is a delegate of the user.
 8. A method,comprising: receiving, by a computer server configured to communicatevia a communications network, a request from a first user to access acomputing resource of the computer server; providing the first useraccess to the computing resource; identifying, by the computer server, asecond user, wherein the computing resource is registered to the seconduser; transmitting, by the computer server, a notification to the seconduser indicating that the first user has been granted to the computingresource; and upon receiving, by the computer server, an indication thatthe permission of the first user to access the computing resource hasbeen revoked, preventing the first user from accessing the computingresource.
 9. The method of claim 8, wherein the notification istransmitted to the second user using a short message service message.10. The method of claim 8, further comprising, before providing thefirst user access to the computing resource, accessing an authenticationdatabase to determine that the second user has previously granted accessto the computing resource to the first user.
 11. The method of claim 8,wherein the computing resource includes at least one of a websitebuilder application, a search engine optimization tool, and an emailservice.
 12. A system, comprising: an authentication databaseassociating at least one user with at least one computing resource; anda computer server configured to communicate with the authenticationdatabase, the computer server being configured to perform the steps of:authenticating a website developer, after authenticating the websitedeveloper, receiving from the website developer a request to access acomputing resource of the computer server, providing the websitedeveloper temporary access to the computing resource, identifying auser, wherein the computing resource is registered to the user,transmitting to the user a request for an authentication credentialgranting the website developer access to the computing resource, andupon receiving the authentication credential, providing the websitedeveloper permanent access to the computing resource.
 13. The system ofclaim 12, wherein the computer server is configured to transmit therequest for the authentication credential to the user using a shortmessage service message.
 14. The system of claim 12, wherein theauthentication credential includes an image.
 15. The system of claim 12,wherein the computer server is configured to perform the steps of,before providing the website developer temporary access to the computingresource, accessing an authentication database to determine that theuser has previously granted access to the computing resource to thewebsite developer.
 16. The system of claim 12, wherein the computingresource includes at least one of a website builder application, asearch engine optimization tool, and an email service.
 17. The system ofclaim 12, wherein the computer server is configured to, after receivingfrom the user the authentication credential, perform the steps of:accessing an authentication database to determine a permission level ofthe website developer for the computing resource; and restrictingactions of the website developer with respect to the computing resourcein accordance with the permission level.
 18. The system of claim 12,wherein the computer server is further configured to perform the stepsof, after receiving from the user the authentication credential, settinga secure cookie on a first user device of the website developer, thesecure cookie indicating that the website developer is a delegate of theuser.